Transparenz für automatisierte und manuelle Tests - ein Erfahrungsbericht aus zwei Jahren Test-Gap-Analyse bei TRUMPF

Im Test möchten wir Fehler finden, bevor diese in Produktion gelangen. Trotzdem gelingt das nicht immer zu 100 Prozent. Studien zeigen, dass das Risiko für Fehler in den Bereichen eines Softwaresystems besonders hoch ist, die seit dem letzten Release geändert, aber nicht im Test ausgeführt wurden. Die Test-Gap-Analyse kombiniert statische und dynamische Verfahren, um bereits während der Entwicklung genau diese Bereiche zu identifizieren und so frühzeitig und kontinuierlich Feedback an Entwickler und Tester zu liefern. TRUMPF setzt die Test-Gap-Analyse bereits im Sommer 2017 im Bereich der .NET-Entwicklung ein, sowohl für automatisierte als auch für manuelle Tests, später wurde sie auch für C++ eingeführt.
 
In diesem Vortrag gibt Dr. Andreas Göb (CQSE GmbH) einen allgemeinen Überblick über die Test-Gap-Analyse und zeigt verschiedene Einsatzszenarien auf, die das von der CQSE entwickelte Werkzeug Teamscale unterstützt. Dr. Stefan Staudt (TRUMPF Werkzeugmaschinen GmbH + Co. KG) gibt einen Einblick in die Hintergründe zur Einführung der Test-Gap-Analyse bei TRUMPF und berichtet von Erfahrungen bei deren Einsatz. Diese beziehen sich nicht nur auf die Analyse und das Werkzeug, sondern umfassen insbesondere auch Herausforderungen und Lösungsansätze bei der Instrumentierung von C++-Anwendungen, um die Testausführung zu messen.
 
Nach positiven Erfahrungen mit der Test-Gap-Analyse im .NET-Umfeld sollte auch für ein bei TRUMPF entwickeltes CAD/CAM-System (Sprache C++, ca. 4,2 MLOC) eingesetzt werden. Da es sich um ein bereits Jahrzehnte existierendes System handelt (positiv ausgedrückt: historisch gewachsen und betriebsbewährt; ehrlich gesagt: an vielen Stellen erodiert), wurde als Ziel ausgegeben, für neuen / geänderten Code festzustellen, inwieweit er durch automatisierte Tests durchlaufen wird. Hierfür bietet Teamscale mit der Test-Gap-Analyse eine große Hilfestellung, da es die Möglichkeit bietet Abdeckung einzelner Tests festzustellen sowie Differenzanalysen unterstützt, um damit die Testabdeckung von neuem und geändertem Code zu bestimmen. Dieser Projektteil ist also ziemlich schnell zu erledigen (was sich auch bewahrheitete).

Als größere Herausforderung erwies sich das Gewinnen der Coverageinformationen an sich: Als die Applikation im 32-Bit-Modus kompiliert und betrieben wurde, konnte mit den Microsoft-Profilerstellungstools wie VSINSTR, … die Coverage ermittelt werden. Allerdings ist 32-Bit nicht mehr ganz zeitgemäß und weist Limitierungen insbesondere bezüglich des möglichen Arbeitsspeichers auf, es sollte also auf 64 Bit portiert werden.

Der erste Ansatz war, die 64-Bit-Binaries mit der 64-Bit-Variante derselben Toolkette in zu instrumentieren. Als die Instrumentierung erfolgreich durchlief und die Tests gestartet werden konnte, hatte ich innerlich den Task schon als erledigt abgehakt. Als allerdings die Umwandlung der binären Coverageinformation in ein verwertbares Format bzw. selbst das Importieren in Visual Studio zuverlässig abstürzte, hatte sich das Erledigen des Tasks erledigt.

Als nächster Ansatz wurde auf die Dynamic Coverage Tools (CodeCoverage.exe) ebenfalls von Microsoft gewechselt. Hier wirkte sich negativ aus, dass die Applikation während des Testablaufs oft neu gestartet wird und dadurch oftmals die Instrumentierung durchgeführt wird. Allerdings erfolgt die Instrumentierung relativ schnell und der Einfluss der Instrumentierung auf die Ausführungszeiten der Tests bewegt im erträglichen Rahmen. Wieder war die Freude groß, als bei diesem Ansatz sogar Coverageinformation entstand und in Teamscale importiert werden konnten. Leider hatte die Coverageinformation ein entscheidendes Problem: sie war falsch (wie durch Debuggen und Codedurchsicht bewiesen wurde); durchlaufene Methoden fehlten. Anfragen in Supportforen waren leider auch nicht von Erfolg gekrönt. Das Projekt entwickelte sich so langsam zu einer neuen Variante von „Täglich grüßt das Murmeltier…“ nur mit anderen Darstellern.

Nächster Ansatz: OpenCppCoverage. Auch hier erfolgt eine dynamische Instrumentierung beim Start der Applikation und die Coverageinformationen passen, allerdings ist der Einfluss auf die Performance erheblich (teilweise Verlangsamung um den Faktor 10!!!), also ist Warten angesagt. Da die Auswahl zwischen schnellen falschen und unperformanten richtigen Ergebnisse zwar nicht toll aber relativ einfach zu entscheiden ist, war wenigstens ein gangbarer Weg verfügbar.

Um einen Ausweg zu finden, wurde zusätzlich ein anderer Ansatz versucht. Instrumentierung des Codes vor dem Kompilieren durch BullseyeCoverage. Hierbei dauert zwar das Kompilieren ca. doppelt so lange, aber da dies nur einmal erfolgen muss, ist das verschmerzbar. Die Performanceeinbußen bewegen sich mit ca. Faktor 1,5 ebenfalls im vertretbaren Rahmen. Als die Ergebnisse in Teamscale importiert werden konnten und plausibel aussahen, konnten auch die Irritationen der Kollegen auf Grund der Jubelschreie leicht verschmerzt werden.

Als nächste Schritte sollen der Ablauf automatisiert werden und in den täglichen Softwareerstellungsprozess eingebunden werden, um eine zeitnahe Auswertung über neue und geänderte Methoden zu erhalten, die nicht bei einem Test durchlaufen wurden.

zurück zum Programm